An early suggestion, I think in terms of warning vs error I would like it to be so that things that directly lead to unintended behavior or rather just the eslint:recommended list to be error, while the stylistic ones to remain as warnings.

There are a few reasons I'm thinking of, the main one is in terms of cognitive understanding with a code editor linter, errors will be highlighted red which should be immediately actioned while warnings highlighted yellow can be dealt with later before commit. We can set ESLint to exit with non-zero exit code on warning as well to get the CI to fail on warning still I believe. That along with a functional eslint-fix should make code style easy enough to work with. Does that make sense to you or do you have a different idea?

An early suggestion, I think in terms of warning vs error I would like it to be so that things that directly lead to unintended behavior or rather just the eslint:recommended list to be error, while the stylistic ones to remain as warnings.

There are a few reasons I'm thinking of, the main one is in terms of cognitive understanding with a code editor linter, errors will be highlighted red which should be immediately actioned while warnings highlighted yellow can be dealt with later before commit. We can set ESLint to exit with non-zero exit code on warning as well to get the CI to fail on warning still I believe. That along with a functional eslint-fix should make code style easy enough to work with. Does that make sense to you or do you have a different idea?

It makes perfect sense. I enabled the stylistic rules in order to get rid of the noise but that's not the correct intention.

To get the CI to fail we'd have to use --max-warnings 0

Once all the fixes we're applied one could reenable .vscode/settings.json#editor.codeActionsOnSave, right? I suggested to disable this setting in order to not accidentally stage any files (via git add .) which weren't intentionally edited by a contributor.

I don't use vscode that much, does .vscode/settings.json#editor.codeActionsOnSave mean it will run eslint fix on save on the saved file? If so we can possible reenable it but the main thing to make sure before that is that there won't be any thing else changing the code beyond our eslint rules, ie. vscode won't change other stylistic stuff that may not be directly covered by our eslint rules like changing whitespace after function name if we don't define it.

I don't use vscode that much, does .vscode/settings.json#editor.codeActionsOnSave mean it will run eslint fix on save on the saved file? If so we can possible reenable it but the main thing to make sure before that is that there won't be any thing else changing the code beyond our eslint rules, ie. vscode won't change other stylistic stuff that may not be directly covered by our eslint rules like changing whitespace after function name if we don't define it.

Yep, that's the purpose of ./vscode/settings.json#"javascript.format.enable": false. Vscode made me go insane before this setting was added.